An increasing number of enterprises demonstrate that a successful adoption of Service Oriented Architecture (SOA) using Web services technologies enables them to develop and integrate applications or solutions quickly and effectively. Compared with conventional techniques, including monolithic system and tightly-coupled client design, Web services provide a new approach for building applications in a loosely coupled, platform independent and standardized manner. Though evolutional, Web services do not escape the necessity of the software lifecycle and one of its most challenging aspects: change management.
In real-world scenarios, Web services always need to change after the original development or deployment to align with changing business requirements. In the total lifecycle of Web services, services can be updated at every stage of the lifecycle. For example, the adding or removing of operations from the interface at design time, bug fixing or adapting another programming language at build-time, changing the deployment server at deployment time, and updating the security policy at runtime. For these changes, a critical issue is to specify the changes and understand their impact to the client. Generally speaking, the impact can be described in terms of compatibility.
A change of a service is termed compatible if no potential client is affected, for example a bug fix. A change is termed as incompatible if there is at least one potential client who would fail when invoking the service after the change, for instance a mandatory parameter is added to the operation in use. In real world scenarios, a web service is like a black-box, so it is hard for the consumers or a third party to specify the compatibility between two versions. Ideally, the service developers would need to address the compatibility of the service changes using some kind of assistant tools and making the compatibility classification task as part of their service development.
The evolution of services often necessitates the co-existence of multiple versions of the same original service. In the SOA model service providers and consumers have independent development and deployment cycles. It is unreasonable to assume that every time a service changes, all of its consumers will rapidly adopt the change by rebuilding and redeploying all their applications. However, if client applications fail to keep track of service changes, businesses supported by the client applications will be inevitably interrupted and suffer undesirable consequences.
While change management is an important aspect in all software development processes, its complexity is increased for Web services due to their loosely coupled nature. A prominent consideration is the impact of the changes in a remote service to a local client application. Consider a case where the public interface of a service remains the same; replacing old versions of the service with new versions would be transparent to the consumers. However, adding a mandatory input parameter to an existing operation, for example, would create a difficult task for the underlying platform because the old version cannot simply be retired; otherwise any consumer depending on that version would be disrupted.
Today service providers use notification messages, such as a release note or an application programming interface (API) upgrade guide, to notify and to help the service developer to update its client applications. The release note or API upgrade guide describes the differences between the new services and the old services, and it is sent out from some service registry, for example a Universal Description, Discovery, and Integration (UDDI) registry, or service provider by emails, forum, discussion community or blogs. When the service developer reads the whole release note or API upgrade guide document then they can determine whether they need to change their client application code.
However, if the release note or API upgrade guide is long or complex or the size of the client application code is huge, it can be very difficult for the developer to locate the part of the code needing adjustment.